Amazon Athena ワークロード分離やクエリの閲覧、コスト管理が可能になるWorkgroups がリリースされました

はじめに

re:Invent2018で発表があった Amazon Athena Workgroups がついにリリースされました。これまでは、同じアカウント内の全てのIAMユーザーがすべてクエリ履歴を参照ことが出来たり、クエリのデータスキャンに対して上限を設定できませんでした。今後は『Workgroups』という仮想的なグループを作ることによって分離・設定・コスト管理ができるようになりました。

• Athena Workgroups を使ってユーザーまたはアプリケーション間のワークロード分離、クエリメトリクスの閲覧、コスト管理の適用を行う

Workgroups とは

Workgroups とは、リソースの分離や上限を設定するための仮想的なグループです。Workgroupを作成して、同じアカウント内のIAMユーザーを割り当てます。リソースや上限はWorkgroup に対して行います。「リソースの分離や上限」と聞いてもピンと来ないかもしれませんので、具体的に何が分離・設定できるかを解説します。

クエリワークロードの分離

ユースケースに応じてWorkgroup毎にクエリの実行条件を設定できるようになります。IAMユーザーが属するWorkgroupのクエリ履歴の参照や実行結果のファイルをダウンロード、暗号化方式など、Workgroupでワークロードを分離できるようになります。

クエリメトリクスの分離

Workgroup毎にデータスキャン量や成功したクエリの数を把握するのに用いることができます。クエリのデータスキャン量や成功の有無を確認することで、Workgroup毎の利用費を把握できます。

クエリ毎のスキャン量上限の設定

クエリ毎にクエリのデータスキャン量の上限を設定できるようになりました。同じworkgroupのIAMユーザーが実行するクエリに対して、指定したサイズ以上のデータスキャンが発生したらクエリを自動キャンセルできます。例えば、運用チーム用のWorkgroupでは制限を設けないが、開発チーム用のWorkgroupにはある程度の上限を設定して、アドホッククエリの使いすぎが生じないようにする、といった対策が可能になりました。この機能は利用者がクエリの使いすぎの防止に役立つ機能です。

Workgroups毎のスキャン量上限の設定

Workgroup毎にクエリのデータスキャン量の上限を設定できるようになりました。設定した上限に達するとSNS経由で通知できます。この機能は利用費を管理者や利用者が使いすぎを認識するのに役立つ機能です。

Workgroupsの設定

Workgroupの作成

Workgroupの作成は、新たに追加されたメニュー（デフォルトは Workgroup : primary）を選択して、Workgroup画面の[Create workgroup]ボタンを押します。

実際に開発チーム用のWorkgroupを作成してみます。「クエリの結果の場所 and Encryption」は、Workgroup毎に設定できるようになり、他のWorkgroupのIAMユーザーがクエリ結果を参照できないようにできます。今回は[Orverride client-side settings]を有効にすることで、クライアント側の設定がある場合でもここで指定したWorkgroupの設定が優先するように設定しています。

開発チーム用 Workgroupdev-wg

クエリ結果の暗号化

上記の[クエリ結果の暗号化]を有効にすると、暗号化の設定項目が表示されます。これまでと同様に暗号化タイプによっては、KMSキーによるサーバーサイド暗号化も指定できます。

Workgroupsの一覧

上の2つは追加したWorkgroupdev-wgとprd-wgです。3つ目のWorkgroupprimaryは、IAMユーザーのデフォルトのWorkgroupになります。既存のIAMユーザーはWorkgroupprimaryから新たに作成したWorkgroupdev-wgやprd-wgに変更（Switch workgroup）できます。

Workgroupの詳細設定

Workgroupの詳細設定するには、Workgroupsの一覧から対象を選択して、[View details]ボタンを押すと詳細が表示します。

開発チーム用 Workgroupdev-wg

クエリ毎のデータ利用量（Per query data usage control）の制限

dev-wgは、[Data usage controls]タブのクエリ毎のデータ利用量（Per query data usage control）の制限を設定します。実行したクエリのスキャンサイズが100MBを超えるとエラーになるように設定しました。

Workgroup毎のデータ利用量（Create workgroup data usage controls）の制限

更にWorkgroup毎のデータ利用量（Create workgroup data usage control）の制限も設定しました。1日のスキャンサイズが500MBを超えるとSystemAlertというSNS topicで通知されます。制限する期間（Time period）は、1日、6時間、1時間、15分、5分、1分のいずれかです。

画面下のWorkgroup data usage controlsの欄に登録した制限が追加されます。更に[作成]ボタンで制限を追加できます。つまり、300MB超えたらWarning、500MB超えたらError、1TB超えたらFatalを呼ぶなんて、段階的に通知するTopicを分けて運用することも可能になります。素晴らしいですね。

IAMユーザーのWorkgroupを切り替える

作成・設定したWorkgroupをIAMユーザーに適用します。

• IAMユーザー cm-dev：Workgroup:primary => Workgroup:dev-wg

では、実際にWorkgroupdev-wgをIAMユーザーcm-devに適用します。名前を選択して、[Switch workgroup]ボタンを押します。

すると、メニューは[Workgroup : dev-wg]に変更されます。

以降では、設定・適用したWorkgroupのユーザーにてデータをアクセスします。

新機能の確認

Workgroup毎のメトリクス表示

sampledb.elb_logsテーブルの「テーブルのプレビュー」を実行します。

「テーブルのプレビュー」を実行すると、メトリクスがプロットされました。また、クエリの結果は「クエリの結果の場所」に指定したS3フォルダの下に保存されました。

スキャンサイズを超えたときのクエリ自動キャンセル機能

実行したクエリのスキャンサイズが100MBを超えるとキャンセルするように設定しましたので、387.76MBスキャンしたこのクエリは、自動的にキャンセルされました。

レコードカウントを実行すると、メトリクスがプロットされました。データのフルスキャンが発生したため、Total data scaned(Megabytes)は、388MBに急上昇していますが、Total success queriesのDMLは増えていませんので課金は発生しないと考えられます。 また、クエリはキャンセルされたため、クエリの結果は「クエリの結果の場所」に指定したS3フォルダの下に保存されないことを確認しました。

指定期間のスキャンサイズの上限を超えたときの通知機能

次は指定期間（１日）のスキャンサイズの上限を超えたときの通知機能について検証します。実行したクエリのスキャンサイズの上限値を100MBから400MBを超えるとキャンセルするように設定を変更しました。レコードカウントを実行すると388MBのデータスキャンが発生します。

メトリックスのTotal data scaned(Megabytes)は、388MBに2回プロットされていますので、２回実行すると上限値の400MBに達します。

スキャンサイズの上限に達するとSNS（email通知）したことが確認できました。上限に達すると以下のようなメーセージが送信されます。

最後に

Workgroupsでクエリワークロードを分離し、データのスキャンサイズに応じてクエリを自動停止したり、SNS通知することができるようになりました。この機能を利用することで、Athenaの不用意な大量データスキャンによるAWS利用費の高額請求が概ね回避できるのではないかと考えられます。

今後、Athenaの実行ユーザーは、デフォルトのWorkgroupprimaryではなく、利用目的に応じたWorkgroupを作成して、リソースの管理することがベストプラクティスと言えるでしょう。まずは、デフォルトのWorkgroupprimaryに運用に支障のない範囲で上限設定を追加することをおすすめします。

個人的な要望としては、システムの安定稼働本番環境のWorkgroupに対して必要なDMLクエリの同時実行数を割り当てられる様になることを期待しています。

合わせて読みたい

[レポート]ANT375-R1:Amazon Athena Workgroupsを使ってグループごとのAthena利用を管理 #reinvent